Pratique de MySQL et PHP by Philippe Rigaux

Auteur:Philippe Rigaux [Rigaux, Philippe]
La langue: fra
Format: epub
Tags: Informatique
Éditeur: O'Reilly
Publié: 2009-06-08T08:20:46+00:00

234

Chapitre 5. Organisation du développement

2. des constructions comme ENUM et SET ;

3. l’auto-incrémentation des clés (option AUTO_INCREMENT de CREATE TABLE).

Il suffit d’ignorer ENUM et SET. Pour les types de données, MySQL propose un

ensemble plus riche que celui de la norme SQL. Le tableau 2.1, page 462, donne la

liste des types disponibles et précise ceux qui appartiennent à la norme SQL ANSI :

il faut se limiter à ces derniers pour une application portable.

Cela étant, certains types très pratiques, comme TEXT, ne sont pas normalisés (ou,

plus précisément, la norme SQL qui préconise BIT VARYING n’est pas suivie). Il est

souvent nécessaire d’utiliser ce type car les attributs de type VARCHAR sont limités à

une taille maximale de 255 caractères. Le type TEXT existe dans PostgreSQL, mais

pas dans ORACLE où son équivalent est le type LONG. Le script de création de notre

schéma, Films.sql, page 202, est entièrement compatible avec la norme, à l’exception

du résumé du film, de type TEXT, qu’il faut donc remplacer par LONG si l’on souhaite

utiliser ORACLE. Ce genre de modification affecte l’installation, et pas l’utilisation

du site, ce qui limite les inconvénients.

Un type normalisé en SQL, mais assez difficile d’utilisation est le type DATE. Dans

le cadre d’une application PHP, le plus simple est de stocker les dates au format dit

« Unix », soit un entier représentant le nombre de secondes depuis le premier janvier

1970. Des fonctions PHP (notamment getDate()) permettent ensuite de manipuler

et d’afficher cette valeur à volonté.

Pour les mots-clés de SQL et les identificateurs, il n’y a pas de problème si on se

limite aux caractères ASCII (mieux vaut éviter les lettres accentuées). L’utilisation

des majuscules et minuscules est en revanche un point délicat. Les mots-clés SQL ne

sont pas sensibles à la casse, et il en va de même des identificateurs. Pour un système

relationnel, toutes les syntaxes suivantes seront donc acceptées, quelle que soit la

casse employée pour créer le schéma :

• SELECT TITRE FROM FILM ;

• select titre from film ;

• Select Titre From Film.

Attention cependant à MySQL qui stocke chaque table dans un fichier dont le

nom est celui donné à la table dans la commande CREATE TABLE. Sous un système

UNIX où les noms de fichiers sont sensibles à la casse, MySQL ne trouvera ni la

table FILM ni la table film si le fichier s’appelle Film. Il faut donc toujours nommer les

tables de la même manière dans la clause FROM, ce qui est facilité par l’emploi d’une

convention uniforme comme – par exemple – une majuscule pour la première lettre

et des minuscules ensuite.

Il faut de plus prendre en compte PHP qui, lui, est sensible à la casse dans les noms

des variables. Les variables $TITRE, $titre et $Titre sont donc considérées comme

différentes. Ces noms de variables sont attribués automatiquement par les fonctions

PHP d’accès aux bases de données comme mysql_fetch_object() (MySQL),

pg_fetch_object() (PostgreSQL), oci_fetch_object() (ORACLE), etc. Tout

Télécharger

Déni de responsabilité:
Ce site ne stocke aucun fichier sur son serveur. Nous ne faisons qu'indexer et lier au contenu fourni par d'autres sites. Veuillez contacter les fournisseurs de contenu pour supprimer le contenu des droits d'auteur, le cas échéant, et nous envoyer un courrier électronique. Nous supprimerons immédiatement les liens ou contenus pertinents.